1. Field of the Invention
The invention relates to a hardware accelerator that accomplishes Winsock protocol acceleration. More particularly, the invention relates to hardware that provides scalable acceleration for processes that call the Winsock data link library (DLL), in which the hardware is detected by the operating system and application program interfaces are routed to hardware acceleration.
2. Background of the Invention
Computer systems require protocol software to communicate with other computers or devices. The protocol software sends information in a particular format, and also receives data in a particular format. Protocols that are commonly used in conventional computer systems include TCP/IP and APPLETALK, as well as many others. The protocol software is typically part of the operating system of the computer.
Operating systems in most computers support multiprogramming, in which multiple application programs are executed simultaneously. Typically, these application programs are run in a time division multiple access structure, in which each application program obtains the entire computer resources for its particular time frame. When executed, an application program runs a particular application, such as "time of day."
An important feature of computer systems is the interface between protocol software and the application programs resident in the computer. Currently, there do not exist standards specifying how application programs interact with protocol software. Since protocol software resides in the operating system of the computer, the interface with application programs depends on the operating system being used (i.e., DOS, OS/2, Windows).
A Winsock interface has been developed, which provides socket functionality for Microsoft Windows. The Winsock interface permits application programs that make socket calls to run Microsoft Windows.
Another important aspect of computer systems is the client-server function. The term "server" applies to any program that offers a service that can be reached over a network. The server accepts the request, typically via a socket assigned to the server. The server then services the request, and transmits the results back to the client. The server then awaits another request.
The term "client" refers to the device that made the request. For example, an executing application program becomes a client when it sends a request to a server and awaits the response. An example of a server is a file server, which receives requests to perform operations that store or retrieve data from a file. The file server performs the requested store/retrieve function, sends the data to the requesting party (the client), and waits for the next request.
A conventional interface between TCP/IP protocol software and application programs running on a UNIX operating system is presented herein. In the UNIX operating system, an application program interacts with the operating system by making system calls. System calls look like other procedure calls from a programmer's perspective, in that they take arguments and return one or more results. Arguments can be binary values or pointers to objects in the application program.
The UNIX input/output (I/O) system uses the "open-read-write-close" paradigm. In this paradigm, a user process calls "open" to specify the file or device to be used and obtains permission to use the file or device. The call to "open" returns a file descriptor, which is an integer value that the process uses when performing I/O operations on the opened file or device.
Once the object is opened, the user process makes one or more calls to "read" or "write" to transfer data to/from the file or device. "Read" transfers data to the user process from the file or device, and "write" transfers data to the file or device from the user process. After all I/O operations are completed, the user process calls "close" to notify the operating system that it has finished using the object.
For input/output operations through a network of devices, the UNIX system utilizes the concept of a "socket." The socket can either be part of the operating system or it can be a library routine that provides a socket interface. The term "socket" provides an endpoint for communication to another device. As with file access, an application program makes a request to the operating system for a socket, and the operating system creates a socket for use by the requesting application program. The operating system returns an integer value that the application program uses to reference the newly created socket.
The main difference between file descriptors and socket descriptors is that the operating system binds a file descriptor to a specific file or device when the application program calls "open", but the operating system can create a socket without binding the socket to a specific destination address. That way, the application program can either supply a destination address each time it uses the socket (i.e., each time it sends a packet of data), or it can bind the destination address to the socket to avoid repeatedly having to specify the destination for data transfers over the same socket.
Like file and device I/O data transfers, data transfers over a socket use operations like read and write. When an application program creates a socket and creates a TCP connection from the socket to a foreign destination, the application program can use "write" to send data across the connection, and the application program at the other end can use "read" to receive the data. In order to allows primitives like "read" and "write" to be used for files, devices and sockets, the operating system allocates socket descriptors and file descriptors from the same set of integer values, so that a particular integer value is either a socket descriptor or a file descriptor, but not both.
In the UNIX operating system, an application program can request a socket on demand. Based on this socket request, the operating system returns a result which includes a first argument specifying the protocol family to be used for the newly created socket (e.g., TCP/IP, PUP internet, APPLETALK), a second argument specifying the type of communications desired (e.g., reliable stream delivery service, connectionless datagram delivery service), and a third argument specifying the specific protocol within the protocol family that is to be used.
At any particular time when the computer is running, there may be various sockets that are open and being used by application programs that are currently being executed. In order to start a new application program, a separate copy of the currently executing application program (or programs) is created, and the new copy replaces itself with the desired application program. The newly created copy then has access to all open sockets as well as all open files. The operating system keeps a reference count associated with each socket, so that it knows how many application programs have access to each socket.
Since both old and new processes have the same access rights to existing sockets, the programmer must ensure that the two processes use the shared sockets without affecting each other. When a process finishes using a socket, it calls "close", and the socket is then no longer usable. When a process terminates for any reason, the operating system closes all sockets accessible by that process.
Initially, a socket is created without it being associated with a local address or a destination address. For TCP/IP protocols, this means that a local protocol port number has not been assigned and a destination port or IP address has not been specified. In many cases, an application program does not care about the local address that it uses, and it is willing to allow the protocol software to choose an address for it. However, a server process that operates on a specified port must be able to specify that port, since that is the only way clients know where to access the server. Once a socket has been created, the server uses the "bind" system call in UNIX to establish a local address for it.
Initially, a socket is created in the unconnected state, so that the socket is not associated with any particular foreign destination. The system call "connect" in UNIX binds a permanent destination address to a socket, and places the socket in the connected state. An application program must first call "connect" to establish a connection before it can transfer data through a socket using a reliable stream datagram service. However, a socket that uses a connectionless datagram service does not need to be connected before it can be used.
Once an application program has established a socket, it can use the socket to transmit data and receive data. In UNIX, there are five possible operating system calls which can be used to send data over a socket: send, sendto, sendmsg, write, and writev. Send, write and writev only work for connected sockets because they do not allow the caller to specify a destination address.
Similarly, in UNIX, there are five possible operating system calls which can be used to receive data over a socket: read, read, recv, recvfrom, and recvmsg. The read system call can only be used when the socket is connected.
Additional operating system calls allow for a newly created process to determine the destination address of an already-existing socket (getpeername), and to obtain and set particular socket options (getsockopt, setsockopt).
For servers, which have a well-known protocol port that all clients can access to submit requests thereto, the operating system call "listen" is used to allow a server to place its socket in a passive mode that is ready to accept connections. The server can also inform the operating system that the protocol software should queue multiple simultaneous requests from different clients that arrive at the socket. If the queue is full when a request arrives, the operating system will refuse the connection and discard the request.
Once a socket has been established, the server waits for a connection, by using the operating system call "accept." When a request arrives, the operating system informs the server of the address of the requesting client, and the operating system creates a new socket that has its destination address connected to the requesting client. The operating system also returns the new socket descriptor to the caller. The original socket remains open, so that the server can continue to accept requests from other clients at the original socket.
When a connection request arrives, the server can either handle the request iteratively or concurrently with other requests. In the iterative approach, the server handles the request itself, closes the new socket, and then call "accept" to obtain the next connection request. In the concurrent approach, after the call to "accept" returns, the server creates a slave process to handle the request. The slave process inherits a copy of the new socket, so it can proceed to service the request. When it finishes, the slave process closes the socket and terminates its own process. The original (i.e., master) server process closes its copy of the new socket after starting the slave process. It then calls "accept" to obtain the next connection request.
The socket interface has currently become popular and is widely supported by many vendors. Vendors who do not offer socket facilities in their operating systems often provide a socket library that makes it possible for programmers to write applications using socket calls even though the underlying operating system uses a different set of system calls.
One such socket interface that is widely used is the Winsock interface, or Winsock, which allows application programs to make socket calls to run with Microsoft Windows, as described earlier. However, with this system, there is not currently available a system that provides for protocol acceleration using Winsock.